Connection: close Content-Type: text/plain

This specification defines protocols, procedures, and conventions to be employed by peers implementing the Generic Security Service Application Program Interface (as specified in RFCs 1508 and 1509) when using Kerberos Version 5 technology (as specified in RFC 1510). ACKNOWLEDGMENTS Much of the material in this Internet-Draft is based on working documents drafted by John Wray of Digital Equipment Corporation and on discussions, implementation activities, and interoperability testing involving Marc Horowitz of OpenVision Technologies, Ted Ts’o of the Massachusetts Institute of Technology (MIT), and John Wray. Thanks are due to each of these individuals for their contributions towards development and availability of GSS-API support within the Kerberos Version 5 code base. 1. Token Formats This section discusses protocol-visible characteristics of the GSSLinn Document Expiration: 31 January 1995 [Page 1] Internet-Draft July 1994 API mechanism to be implemented atop Kerberos V5 security technology per RFC-1508 and RFC-1510; it defines elements of protocol for interoperability and is independent of language bindings per RFC1509. Tokens transferred between GSS-API peers (for security context management and per-message protection purposes) are defined. The data elements exchanged between a GSS-API endpoint implementation and the Kerberos KDC are not specific to GSS-API usage and are therefore defined within RFC-1510 rather than within this specification. To support ongoing experimentation, testing, and evolution of the specification, the Kerberos V5 GSS-API mechanism as defined in this and any successor Internet-Drafts will be identified with the following Object Identifier, as defined in RFC-1510, until the specification is advanced to the level of Proposed Standard RFC: {iso(1), org(3), dod(5), internet(1), security(5), kerberosv5(2)} Upon advancement to the level of Proposed Standard RFC, the Kerberos V5 GSS-API mechanism will be identified by an Object Identifier having the value: {iso(1) member-body(2) United States(840) mit(113554) infosys(1) gssapi(2) krb5(2)} 1.1. Context Establishment Tokens Per RFC-1508, Appendix B, the initial context establishment token will be enclosed within framing as follows: InitialContextToken ::= [APPLICATION 0] IMPLICIT SEQUENCE { thisMech MechType -MechType is OBJECT IDENTIFIER -representing "Kerberos V5" innerContextToken ANY DEFINED BY thisMech -contents mechanism-specific; -ASN.1 usage within innerContextToken -is not required } The innerContextToken of the initial context token will consist of a Kerberos V5 KRB_AP_REQ message, preceded by a two-byte token-id (TOK_ID) field, which shall contain the value 01 00. The above GSS-API framing shall be applied to all tokens emitted by the Kerberos V5 GSS-API mechanism, including KRB_AP_REP, KRB_ERROR, Linn Document Expiration: 31 January 1995 [Page 2] Internet-Draft July 1994 context-deletion, and per-message tokens, not just to the initial token in a context establishment sequence. While not required by RFC-1508, this enables implementations to perform enhanced errorchecking. The innerContextToken field of context establishment tokens for the Kerberos V5 GSS-API mechanism will contain a Kerberos message (KRB_AP_REQ, KRB_AP_REP or KRB_ERROR), preceded by a 2-byte TOK_ID field containing 01 00 for KRB_AP_REQ messages, 02 00 for KRB_AP_REP messages and 03 00 for KRB_ERROR messages. Relevant KRB_AP_REQ syntax (from RFC-1510) is as follows: AP-REQ ::= [APPLICATION 14] SEQUENCE { pvno [0] INTEGER, -indicates Version 5 msg-type [1] INTEGER, -indicates KRB_AP_REQ ap-options[2] APOptions, ticket[3] Ticket, authenticator[4] EncryptedData } APOptions ::= BIT STRING { reserved (0), use-session-key (1), mutual-required (2) } Ticket ::= [APPLICATION 1] SEQUENCE { tkt-vno [0] INTEGER, -indicates Version 5 realm [1] Realm, sname [2] PrincipalName, enc-part [3] EncryptedData } -Encrypted part of ticket EncTicketPart ::= [APPLICATION 3] SEQUENCE { flags[0] TicketFlags, key[1] EncryptionKey, crealm[2] Realm, cname[3] PrincipalName, transited[4] TransitedEncoding, authtime[5] KerberosTime, starttime[6] KerberosTime OPTIONAL, endtime[7] KerberosTime, renew-till[8] KerberosTime OPTIONAL, caddr[9] HostAddresses OPTIONAL, authorization-data[10] AuthorizationData OPTIONAL } -Unencrypted authenticator Linn Document Expiration: 31 January 1995 [Page 3] Internet-Draft July 1994 Authenticator ::= [APPLICATION 2] SEQUENCE { authenticator-vno[0] INTEGER, crealm[1] Realm, cname[2] PrincipalName, cksum[3] Checksum OPTIONAL, cusec[4] INTEGER, ctime[5] KerberosTime, subkey[6] EncryptionKey OPTIONAL, seq-number[7] INTEGER OPTIONAL, authorization-data[8] AuthorizationData OPTIONAL } For purposes of this specification, the authenticator shall include the optional sequence number, and the checksum field shall be used to convey the channel bindings. The checksum will have a type of 0x8003 (within the set of negative 16-bit values reserved by Kerberos for application use), and a 24-byte value field, as follows: Byte Name Description 0..3 Lgth Number of bytes in Bnd field; Currently contains hex 10 00 00 00 (16, represented in little-endian form) 4..19 Bnd MD5 hash of channel bindings, taken over all non-null components of bindings, in order of declaration. Integer fields within channel bindings are represented in little-endian order for the purposes of the MD5 calculation. 20..23 Flags Bit vector of context-establishment flags, with values consistent with RFC-1509, p. 41: GSS_C_DELEG_FLAG: 1 GSS_C_MUTUAL_FLAG: 2 GSS_C_REPLAY_FLAG: 4 GSS_C_SEQUENCE_FLAG: 8 GSS_C_CONF_FLAG: 16 GSS_C_INTEG_FLAG: 32 The resulting bit vector is encoded into bytes 20..23 in little-endian form. In computing the contents of the "Bnd" field, the following detailed points apply: (1) Each integer field shall be formatted into four bytes, using little-endian byte ordering, for purposes of MD5 hash computation. (2) All input length fields within gss_buffer_desc elements of a gss_channel_bindings_struct, even those which are zero-valued, shall be included in the hash calculation; the value elements of Linn Document Expiration: 31 January 1995 [Page 4] Internet-Draft July 1994 gss_buffer_desc elements shall be dereferenced, and the resulting data shall be included within the hash computation, only for the case of gss_buffer_desc elements having non-zero length specifiers. (3) If the caller passes the value GSS_C_NO_BINDINGS instead of a valid channel bindings structure, the Bnd field shall be set to 16 zero-valued bytes. It is anticipated that future extensions to this specification may add new features by suffixing additional data following the checksum value field as defined above. In order that such extended implementations may remain interoperable with implementations based on the current specification, implementations of this Internet-Draft shall be capable of accepting checksum value fields with Lgth specifiers indicating 24 bytes or greater. Processing procedures for data elements within the checksum value field but after the Flags are not, however, currently defined. A context establishment sequence based on the Kerberos V5 mechanism will perform one-way authentication (without confirmation or any return token from target to initiator in response to the initiator’s KRB_AP_REQ) if the mutual_req bit is not set in the application’s call to gss_init_sec_context(). Applications requiring confirmation that their authentication was successful should request mutual authentication, resulting in a "mutual-required" indication within KRB_AP_REQ APoptions and the setting of the mutual_req bit in the flags field of the authenticator checksum. In response to such a request, the context target will reply to the initiator with a token containing either a KRB_AP_REP or KRB_ERROR, completing the mutual context establishment exchange. Relevant KRB_AP_REP syntax is as follows: AP-REP ::= [APPLICATION 15] SEQUENCE { pvno [0] INTEGER, -represents Kerberos V5 msg-type [1] INTEGER, -represents KRB_AP_REP enc-part [2] EncryptedData } EncAPRepPart ::= [APPLICATION 27] SEQUENCE { ctime [0] KerberosTime, cusec [1] INTEGER, subkey [2] EncryptionKey OPTIONAL, seq-number [3] INTEGER OPTIONAL } The optional seq-number element within the AP-REP’s EncAPRepPart Linn Document Expiration: 31 January 1995 [Page 5] Internet-Draft July 1994 shall be included. The syntax of KRB_ERROR is as follows: KRB-ERROR ::= [APPLICATION 30] SEQUENCE { pvno[0] INTEGER, msg-type[1] INTEGER, ctime[2] KerberosTime OPTIONAL, cusec[3] INTEGER OPTIONAL, stime[4] KerberosTime, susec[5] INTEGER, error-code[6] INTEGER, crealm[7] Realm OPTIONAL, cname[8] PrincipalName OPTIONAL, realm[9] Realm, -Correct realm sname[10] PrincipalName, -Correct name e-text[11] GeneralString OPTIONAL, e-data[12] OCTET STRING OPTIONAL } Values to be transferred in the error-code field of a KRB-ERROR message are defined in [RFC-1510], not in this specification. 1.2. Per-Message and Context Deletion Tokens Three classes of tokens are defined in this section: "Sign" tokens, emitted by calls to gss_sign() and consumed by calls to gss_verify(), "Seal" tokens, emitted by calls to gss_seal() and consumed by calls to gss_unseal(), and context deletion tokens, emitted by calls to gss_delete_sec_context() and consumed by calls to gss_process_context_token(). Several variants of cryptographic keys are used in generation and processing of per-message tokens: (1) context key: uses Kerberos session key (or subkey, if present in authenticator emitted by context initiator) directly (2) confidentiality key: forms variant of context key by exclusive-OR with the hexadecimal constant f0f0f0f0f0f0f0f0. (3) MD2.5 seed key: forms variant of context key by reversing the bytes of the context key (i.e. if the original key is the 8-byte sequence {aa, bb, cc, dd, ee, ff, gg, hh}, the seed key will be {hh, gg, ff, ee, dd, cc, bb, aa}). 1.2.1. Per-message Tokens Sign Linn Document Expiration: 31 January 1995 [Page 6] Internet-Draft July 1994 Use of the gss_sign() call yields a token, separate from the user data being protected, which can be used to verify the integrity of that data as received. The token has the following format: Byte no Name Description 0..1 TOK_ID Identification field. Tokens emitted by gss_sign() contain the hex value 01 01 in this field. 2..3 SGN_ALG Integrity algorithm indicator. 00 00 DES MAC MD5 01 00 MD2.5 02 00 DES MAC 4..7 Filler Contains ff ff ff ff 8..15 SND_SEQ Sequence number field. 16..23 SGN_CKSUM Checksum of "to-be-signed data", calculated according to algorithm specified in SGN_ALG field. GSS-API tokens must be encapsulated within the higher-level protocol by the application; no embedded length field is necessary.